Real-time event monitoring system for basketball-related activities

ABSTRACT

An event monitoring system for tracking, tabulating and displaying in real-time player and team performance statistics and events (such as scores, shot percentages, ball possessions, steals, rebounds and turnovers) during a basketball game or basketball-related activity involving a basketball goal, a plurality of players, and a basketball equipped with active or passive RFID tags. The system includes a plurality of wireless ball trackers worn on the wrists of participating players and officials, or attached to the goals, and a wireless mobile computing device with an event monitoring program and a set of data objects configured to store data representing current and historical events and performance statistics associated with the basketball activity and participants. The event and performance data may be displayed on a display screen associated with the mobile computing device in real-time and/or uploaded to and displayed on a connected scoreboard or cloud-based server.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to and claims priority under 35 U.S.C. §119 to U.S. provisional patent application No. 62/060,694, filed on Oct. 7, 2014, which is incorporated into this application in its entirety by this reference.

FIELD OF ART

The present invention relates generally to automated systems and methods for detecting, recording, tracking, tabulating and displaying shooting statistics (such as the number of attempted shots, missed shots and successful shots) and other events (such as ball possessions, passes, assists, rebounds, steals and turnovers) that could occur during a basketball game, drill or scrimmage for an individual basketball player, or for one or more teams of basketball players. More particularly, the present invention relates to systems and methods that utilize radio frequency identification (RFID) sensors, mobile computers and wireless data transmissions to detect, identify and track players, officials and basketballs during a game of basketball.

BACKGROUND

There are a considerable number of basketball games and activities, which involve: (1) a large number of participating players, some of whom may be moving, dribbling and/or shooting in relatively unconventional, inconsistent and unpredictable ways; (2) a large number of basketballs being shot on a single basketball goal at substantially the same time, (3) multiple basketball players shooting multiple basketballs at multiple basketball goals at substantially the same time, (4) frequent and unpredictable changes in ball possessions, (5) important game events (e.g., passes, shot attempts, steals or turnovers) taking place at significant distances away from one or both of the basketball goals, such as at half-court or at the far end of the court, and (6) venues where there is likely to be a large number of other wireless devices in close proximity to the court. Examples of these games and activities may include, for example, full-court games of five-on-five team competitions, basketball team practices and shoot-arounds, high-school, college and professional games taking place in large arenas with lots of spectators with cellphones, etc. Under these conditions, it is conceivable that conventional basketball game event tracking systems, which rely on wireless tracking devices, motion sensors and transmitters could become overwhelmed, and therefore may not operate as effectively or as accurately as they would under other basketball playing conditions.

Accordingly, there is a need in the sport of basketball for improved methods for tracking shots in situations where players may be moving their arms and wrists in unusual and unconventional ways while dribbling, passing and shooting the basketball. There is also considerable need in the sport of basketball for automated systems and methods for tracking shots and ball possessions in basketball situations involving full-court team competition, or a multiplicity of basketball players, or a multiplicity of basketballs, or a multiplicity of basketball goals being shot at substantially simultaneously, or venues where there are potentially a large number of wireless devices close to the court, or a combination of two or more these conditions.

BRIEF SUMMARY OF EXEMPLARY EMBODIMENTS OF THE INVENTION

Embodiments of the present invention address these needs by providing systems and methods for detecting, tracking and tabulating shot attempts and made shots for one or more basketball players shooting with one or more basketballs on one or more basketball goals in practice or game situations. These shot attempts and made shots may occur on a single basketball goal at substantially the same time, on multiple basketball goals at substantially the same time, or on single or multiple basketball goals at different times. In game situations, where multiple players are shooting a single basketball against two basketball goals at different times, embodiments of the present invention may be configured, not only to track shooting statistics of individual players and teams, but also may be configured to tabulate made shots and display the current scores of the teams on a connected smart scoreboard. In addition, embodiments of the present invention also may be configured to detect and track other game events associated with changes in ball possession, such as passes, rebounds, scoring assists, steals and turnovers. Embodiments of the present invention are also capable of detecting and tracking shot attempts in situations where the physical movements of the players taking the shots do not necessarily match or simulate the conventional shooting forms or a typical motion profile for taking shots with a basketball.

In one embodiment of the present invention, passive RFID emitters (also known as “passive RFID transponders”) are attached to the lining or to some other interior or exterior section of a basketball, while all of the players on the basketball court wear player tracking devices on each wrist, each player tracking device including an RFID reader configured to emit electromagnetic energy waves that energize and activate the passive RFID emitters attached to the basketball. Thus, when a particular player touches, catches and/or dribbles the basketball, the passive RFID emitters attached to the basketball come within range of the RFID reader in the player tracking device on at least one of that player's wrists, which energizes one or more of the RFID emitters attached to the basketball. The energized passive RFID emitters attached to the basketball transmit a unique identifier (such as a serial number) for the basketball to the RFID reader in the player tracking device. When the player tracking device receives the unique identifier for the basketball from the RFID emitter attached to the basketball, the player tracking device transmits the basketball's unique identifier, along with a player identification code, to a event monitoring program running on a nearby mobile computing device, such as a smartphone, tablet computer or laptop computer. Upon receiving the unique player identification code and the unique ball identifier for the basketball, the event monitoring program running on the mobile computing device records that the identified player is now in possession of the identified basketball.

From that point on, the player tracking device worn on the player's wrists will repetitively check to confirm that the RFID emitters embedded in the identified basketball are still within range of one or both of the RFID readers in the wrist-worn player tracking devices. When the RFID readers in the player tracking devices worn on the player's wrists no longer detect the presence of the RFID emitters attached to the basketball, it means the player no longer has possession of the basketball. A player losing possession of a ball is an indication of several types of basketball game events, including, but not limited to, the player shooting the ball toward the basketball goal, the player passing the ball to another player, another player stealing the ball away from that player, or that player simply letting go of control of the ball (e.g., by throwing the basketball away or by giving the basketball to a referee). In any of these situations, one or both of the player tracking devices on the player's wrists will send a message to the event monitoring program running on the mobile device, the message indicating that the particular player no longer has possession of the ball.

In the event of a player shooting the ball towards the basketball goal, two RFID readers placed on (or very near) the basketball goal will sense the proximity of the ball when the ball comes close to the structure of the basketball goal and/or passes through the net. A first RFID reader, referred to herein as a far-field RFID reader, which is typically located above and behind the rim, is configured to detect when the basketball enters a relatively large, spherically-shaped three-dimensional zone around the goal, the three-dimensional zone typically encompassing the whole backboard, the whole rim and the whole net, or at least portions of the backboard, the rim and the net. When the far-field RFID reader detects that a basketball has entered this large three-dimensional zone, a processor and transmitter associated with the far-field RFID reader will send a message to the event monitoring program running on the mobile computing device, the message indicating that a shot-attempt event has occurred. The shot-attempt event message also provides the event monitoring program with the unique identifiers for the basketball and the basketball goal.

The second RFID reader on or near the goal, referred to herein as the near-field RFID reader, is located inside or just behind the net and configured to detect when the basketball passes through a smaller three-dimensional zone located just underneath the rim of the basketball goal. This smaller three-dimensional zone encompasses the space typically encompassed by a standard basketball net attached to the rim. When the near-field RFID reader detects that a basketball has entered this smaller three-dimensional zone underneath the rim, it can be assumed that the basketball has passed through the rim and the net. When this occurs, a processor and transmitter associated with the near-field RFID reader will send a message to the event monitoring program running on the mobile computing device, the message indicating that a made-shot event has occurred. The made-shot event message also provides the event monitoring program with unique identifiers for the basketball and the basketball goal.

Because the event monitoring program running on the mobile computing device is constantly receiving and processing event messages indicating which player has a particular basketball, which player has just lost possession of that particular basketball, whether a shot-attempt event has occurred, which basketball was used in the shot-attempt event, whether the shot was made or missed, and which basketball passed through the rim and the net to cause the made-shot event, the event monitoring program running on the mobile computing device is able to determine in real time and record in memory which player took the shot resulting in a hit or miss, and is further able update the shot statistics for that player, as well as the shot statistics and/or score for that player's team. Moreover, if the event monitoring program running on the mobile computing device detects a loss of ball possession by a particular player, followed by another player gaining possession, without a shot-attempt or made shot event occurring within a predetermined time period after the change in possession, then the event monitoring program running on the mobile computing device is configured to record and store in memory that the event that has just occurred was either a turnover, pass or a steal, depending on the identities of the players who lost and gained possession of the ball.

In some embodiments of the present invention, the referees and other game officials also wear on both wrists game official tracking devices with RFID readers, which also transmit messages to the event monitoring program running on the mobile computing device, the messages indicating the game officials' unique identification codes and possessions of the ball. This permits the event monitoring program running on the mobile computing device to determine in real time and record in memory basketball events that are typically associated with officials handling the basketball, such as official timeouts, free-throws, stoppage of play, shot-clock violations, out-of-bounds plays, jump balls, end of game calls, etc. Preferably, all or most of this information may then be recorded and used by embodiments of the present invention to track and display a host of important game details, including without limitation, scores, team fouls, team turnovers, team rebounds, time outs remaining for a team, etc.

Accordingly, the present invention provides a real-time event monitoring system for a basketball-related activity involving a basketball goal, a plurality of players, and a basketball equipped with an RFID tag configured to transmit a radio frequency signal encoded with a ball ID for the basketball. The RFID tag in the basketball could be a “passive” RFID tag, which transmits the radio frequency signals encoded with a ball ID in response to being interrogated by the RFID readers in the player trackers. Alternatively, the RFID tag in the basketball could be an “active” RFID tag, which is battery-powered and periodically transmits the ball ID to any listening RFID reader (at 10 Hz intervals, for example) without first being interrogated by an RFID reader. The real-time event monitoring system comprises a mobile computing device, a plurality of player tracking devices and one or more goal tracking devices. The mobile computing device includes a wireless communications interface, a microprocessor, a memory, an event monitoring program stored in the memory, and a set of data objects stored in the memory, the set of data objects arranged to store for each player in the plurality of players, a player ID, a player tracker ID, a ball ID and a player performance statistic. Examples of player performance statistics include, for example, shot attempts, made shots, passes, assists, steals, turnovers, etc.

The plurality of player tracking devices are configured to be worn by the plurality of players participating in the basketball-related activity, respectively. Each one of the player tracking devices includes a radio frequency transceiver for wireless communication with the mobile computing device, as well as a player RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag on the basketball if the basketball is in reading range of the player RFID reader. Each player tracking device also includes a player data processing unit programmed to (i) determine that the player wearing the player tracking device has gained or lost possession of the basketball based on an output from the player RFID reader, and (ii) transmit a possession change event message to the mobile computing device via the radio frequency transceiver indicating that the player has gained or lost possession of the basketball. The possession change event message may include, among other things, the player ID for the player, the ball ID for the basketball, and a possession change event type (e.g., a steal or out-of-bounds play). In certain specific embodiments, each player wears a pair of player tracking devices, with one player tracking device on each wrist, relatively close to the player's hands. However, in other embodiments, a single player tracking device, with a suitably configured reading range for the RFID reader, may be attached to some other part of each player's body, e.g., strapped to player's upper arm, chest, leg or abdomen, or attached to each player's clothes or shoe. Thus, depending on the strength of the radio frequency signals transmitted by the ball tags in the basketballs, as well as the reading ranges and orientations of the RFID readers in the player tracking devices, embodiments of the present invention may utilize a single player tracking device attached to the clothes or body of each player, or multiple player tracking devices attached to the clothes or body of each player.

The goal tracking device, which is configured for attachment to the basketball goal or goals, comprises a goal radio frequency transceiver for wireless communication with the mobile computing device, and a goal RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag of the basketball if the basketball is in reading range of the goal RFID reader. It also includes a goal data processing unit programmed to (i) determine that a shot has been taken based on an output from the goal RFID reader, and (ii) transmit a shot event message to the mobile computing device via the goal radio frequency transceiver. The shot event message, which indicates that the shot has been taken, typically includes the goal ID and the ball ID (although other data, such as event timestamps, may also be included).

Importantly, the event monitoring program on the mobile computing device includes program instructions that, when executed by the microprocessor of the mobile computing device, will cause the microprocessor on the mobile computing device to carry out two functions: (i) to determine which player in the plurality of players shot the basketball on the basketball goal based on the possession change event message, the shot event message, and one or more values stored in the set of data objects in the memory, and (ii) to record a change in the player performance statistic for the player who shot the basketball. Ideally, the event monitoring program is also configured to display the changed performance statistic on a connected display screen and/or transmit the change to a connected smart scoreboard or cloud-based server for further processing and/or distribution. In addition to determining which player shot the ball, certain embodiments of the present invention are also able to determine, track and display team statistics, such as team scores, team shot attempts, team turnovers, team steals, team rebounds, etc.

The event monitoring system of the present invention may further include one or more referee tracking devices configured to be worn on the wrists of the referees or other game officials involved in the basketball-related activity. These referee tracking devices include a radio frequency transceiver for wireless communication with the mobile computing device and a referee RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag on the basketball whenever the basketball is in reading range of the referee RFID reader (i.e., when the basketball is in a referee's hands). The referee tracking devices also have a data processing unit programmed to (i) determine that the referee wearing the referee tracking device has gained or lost possession of the basketball based on an output from the referee RFID reader, and (ii) transmit a game stoppage event message to the mobile computing device via the radio frequency transceiver. Typically, the game stoppage event message includes a referee ID for the referee handling the ball, as well as the ball ID for the basketball being handled by the referee.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a high-level block diagram illustrating a basketball event monitoring system configured to operate in accordance with one embodiment of the present invention, wherein the RFID emitters embedded in the basketballs are passive RFID emitters.

FIG. 2 contains a high-level block diagram illustrating by way of example some of the major physical components of the player tracking devices, net tracking devices and goal tracking devices in one embodiment of the basketball event monitoring system of the present invention, wherein the RFID emitters embedded in the basketballs are passive RFID emitters.

FIGS. 3A, 3B, and 3C show basketballs configured to operate in accordance with one embodiment of the basketball event monitoring system of the present invention, the basketball being equipped with a plurality of passive RFID emitters.

FIG. 4 shows a high-level block diagram illustrating by way of example a basketball event monitoring system configured to operate in accordance with one embodiment of the present invention, wherein the RFID emitters embedded in the basketballs are active RFID emitters.

FIG. 5A contains an illustration of the cross-section of a basketball with a single ball tag embedded therein.

FIG. 5B contains a schematic diagram illustrating the location and ranging of the single ball tag with the active RFID emitter and the RFID reader in the player tracker when a player holds the basketball.

FIG. 6 shows an exemplary printed circuit board for the goal trackers, player trackers and ball tags for the active RFID tag version of the ball possession and shot-tracking system of the present invention.

FIGS. 7A and 7B contain illustrations showing the positions of two goal trackers attached to a basketball goal in accordance with an embodiment of the present invention.

The diagram of FIG. 8 is provided to illustrate and help describe the interaction between the ball tags, the player trackers, the goal trackers and the event monitoring program stored in the memory of the mobile computing device and executed by microprocessor in the present invention.

FIG. 9 is a high-level flow diagram illustrating an exemplary algorithm for a program executed by the data processing unit in the active RFID basketball in one embodiment of the present invention.

FIG. 10 is a high-level flow diagram illustrating by way of example an algorithm for a program executed by the data processing unit in the player trackers worn on the players' wrists in one embodiment of the present invention.

FIG. 11 shows a high-level flow diagram illustrating by way of example an algorithm for the “ball possession loop,” executed by the program running on the player tracker in one embodiment of the present invention.

FIG. 12 is a high-level flow diagram showing by way of example one algorithm for a program running on the microprocessor of the far field goal tracker to detect shot attempts in an embodiment of the present invention.

FIG. 13 is a high level flow diagram illustrating by way of example one algorithm for a program running on the near field goal tracker attached to a basketball goal to detect made shots in an embodiment of the present invention.

FIG. 14 is a high-level flow diagram showing by way of example one algorithm for a thread of the event monitoring program running on the mobile computing device in an embodiment of the present invention.

FIG. 15 is a high-level flow diagram showing by way of example one algorithm for the main processing thread of the event monitoring program running on the mobile computing device in an embodiment of the present invention.

FIG. 16 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a player tracker sends a message indicating that a player has acquired possession of a basketball with either an active or a passive RFID emitter.

FIG. 17 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a player tracker sends a message indicating that a player has lost possession of a basketball with either an active or a passive RFID emitter.

FIG. 18 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a goal tracker sends a message indicating that a shot attempt has occurred using a basketball having either an active or a passive RFID emitter.

FIG. 19 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a goal tracker sends a message indicating that a made shot event has occurred using a basketball having either an active or a passive RFID emitter.

FIG. 20 is a high-level flow diagram illustrating by way of example one algorithm that could be executed by a program thread running on the player trackers worn on the players' wrists in one embodiment of the present invention.

FIG. 21 is a high-level flow diagram illustrating by way of example one algorithm for the “waiting for stop” thread spawned by one of the steps in FIG. 12 to determine whether the primary thread being executed on the far field goal tracker should terminate.

FIG. 22 is a high-level block diagram illustrating by way of example some of the data objects that could be used in embodiments of the present invention to record, track and look up properties and values associated with the basketballs, the players, the teams, the wrist trackers, and the goal trackers, as well as player and team performance statistics, like shot-attempts, made shots, steals and turnovers.

In this disclosure, the last two digits of each reference numeral identify a given component, element, or algorithm step, and the preceding one or two digits of each reference numeral correspond to the number of the figure in which the element or step is depicted. Thus, if a given element is shown in multiple figures, strictly speaking, the element will have different reference numerals in each of the several figures; however, the last two digits will be the same across all related figures being discussed at the same time in order to explain a particular concept or aspect of embodiments of the invention. For example, the same generalized computing device is depicted in FIGS. 1 and 4 as element numbers 108 and 408, respectively. If multiple figures are being addressed at the same time within this disclosure, just the reference numeral used in the lowest-numbered figure will be used in the text. Furthermore, different elements that are illustrated in different figures, and which are discussed at different points within this disclosure, likely will have reference numerals in which the last two digits are the same. The fact that the elements are being discussed at different points in the disclosure should, however, prevent such commonality of the last two reference-numeral digits from causing confusion.

Finally, one of the flow diagrams in this disclosure spans multiple drawing sheets. See the flow diagrams depicted in FIGS. 10 and 11. In such cases, “flow chart connectors” are used to connect the diagrams and indicate how the system progresses from the flow diagram on one drawing sheet to the flow diagram of another drawing sheet. In particular, flow chart connector labels (e.g., “FC1”) inside circular shapes indicate “incoming” flows, while flow chart connector labels inside pentagon-shaped objects indicate “outgoing” flows.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1 shows a high-level block diagram illustrating a basketball event monitoring system 100 configured to operate according to one embodiment of the present invention. In this embodiment, the RFID tags 160 a-160 n attached to the basketballs have passive RFID emitters 162. As shown in FIG. 1, the system comprises a mobile computing device 105, one or more goal trackers 120 a-120 n, a plurality of player trackers 140 a-140 n, and a plurality of ball tags 160 a-160 n. In a preferred embodiment, the system may also include an optional cloud-based server 170 for long term basketball data storage and sharing, and a smart scoreboard 115 for keeping track of player and/or team scoring totals. In some embodiments, the system may also include a plurality of game official trackers (not shown in FIG. 1), which will be worn on each wrist of the basketball game officials, and configured to operate in substantially the same manner as the player trackers 140 a-140 n, which are described in more detail below.

The mobile computing device 105 typically comprises a hand-held or portable computer system, such as smart phone, tablet computer, or laptop computer. However, it will be appreciated by those in the art that, although a mobile computing device is preferred, a non-mobile (or less portable) computing device, such as a desktop computer system or workstation (not shown in FIG. 1), also could be used in place of the mobile/portable computing device 105, to run the event monitoring programs and carry out the functions performed on the mobile computing device 105, as described in more detail below. The cloud-based server 170 comprises one or more networked computer systems existing in a local or wide-area network, such as the Internet, typically accessed by the mobile computing device 105 via a standard wireless or wired data communications channels (e.g., Ethernet, cable, WiFi, etc.).

In certain embodiments, two goal trackers are attached to each basketball goal. (For brevity and ease of understanding, the basketball goals are not shown in FIG. 1) Every goal tracker attached to a basketball goal has a unique identification code, which is associated in the data objects 109 of the mobile computing device 105 with the particular goal to which the goal tracker is attached. In game and practice situations, each player participating in the game or practice session wears one of the player trackers 140 a-140 n on each wrist, preferably on the underside of the wrist, relatively close to that player's hands. Thus, if ten players are on the court, then the ideal configuration of the system will include twenty player trackers (assuming every player has two wrists and uses both wrists while playing basketball). A more ideal configuration of the system provides two player trackers for every player on a team, even though some of the players may be sitting on the bench during certain parts of the game, so that the player trackers 140 a-140 n do not have to be shared or switched between the players as the players enter and leave the game. If the activity is an officiated basketball game, then each one of the game officials (e.g., referees) may also wear a game official tracker (not shown in FIG. 1) on each wrist, so that the system will be able to detect and record when the game officials have possession of the basketball, such as during a timeout or just after a turnover or a foul has been called. Each player tracker in the plurality of player trackers 140 a-140 n, and each game official tracker worn by a game official, has a unique identification code that is associated in the memory of the mobile computing device 105 with a particular player or game official. See FIG. 22 for a schematic example of the associations. As shown in FIG. 22, the data objects may include hash maps to expedite looking up and retrieving certain player, ball and goal tracker properties.

One or more ball tags 160 a-160 n are attached to the lining, interior or exterior section of each basketball used for the game, scrimmage or practice, each one of the ball tags 160 a-160 n having a passive RFID emitter 162 (sometimes referred to as a passive RFID transponder). Each basketball may contain one or multiple ball tags 160 a-160 n. Each passive RFID emitter 162 is configured to transmit a unique ball identifier (such as a serial number) to an RFID reader when the ball tag 160 a-160 n and the passive RFID emitter 162 passes into the field of view of the RFID reader. The goal trackers 120 a-120 n and the player trackers 140 a-140 n each have an RFID reader 122 and 142, respectively, configured to use electromagnetic energy to activate the passive RFID emitter 162 in each one of the ball tags 160 a-160 n whenever that particular basketball passes into the field of view (or reading range) of the RFID reader in the goal tracker, player tracker or game official tracker. Thus, when a basketball is shot toward one of the goal tracker 120 a-160 n, or is touched, caught and/or held by a player or game official, the passive RFID emitter 162 in that basketball responds to an interrogation signal transmitted by the RFID reader in the goal or player tracker by transmitting a radio frequency signal encoded with a unique identifier for the basketball. The radio frequency signals are detected and decoded by the RFID readers in the goal trackers, the player trackers and the game official trackers.

The goal trackers 120 a-120 n, the player trackers 140 a-140 n and the game official trackers (the game official trackers are not shown in FIG. 1) are all configured to detect and decode the radio frequency signals emitted by the ball tags, and then transmit the encoded ball identifiers to the mobile computing device 105, along with the unique identifier associated with the goal tracker, the player tracker or game official tracker that received and decoded the signal. The mobile computing device 105 uses the goal tracker ID, ball ID, player tracker ID and game official tracker ID to determine and record the fact that a change in ball possession event, and/or a shot-attempt event and/or a made-shot event has occurred in the game. The mobile computing device 105 stores the events to keep track of ball possessions, passes, steals, assists, shot-attempts, made-shots, rebounds, timeouts and turnovers. In preferred embodiments, part or all of this information is transmitted to the cloud-based server 170 for long-term storage and analysis by spectators, fans and other users. In some embodiments, the shot-attempts and made-shots for a specific player or team may be tabulated and transmitted to a smart scoreboard 115 that includes a score displaying application 117 capable of displaying player and team scoring.

The mobile computing device 105 typically contains memory (not shown), a microprocessor (also not shown), and one or more two-way RF transceivers 102 capable of communicating via RF transmissions (e.g., BLE, WiFi, ANT, etc.) with the goal trackers 120 a-120 n and player trackers 140 a-140 n. An event monitoring program 108, stored in the memory of the mobile computing device 105, contains programming instructions that cause the microprocessor in the mobile computing device 105 to tabulate and store in the memory data representing ball possessions, changes in ball possession, shot-attempt events, made shot events, passes, assists, rebounds, total scores, timestamps for shot-attempts and made shots, etc. Ideally, the event monitoring program 108 is a multithreaded application having two primary threads of operation—one thread of operation for establishing a local mobile network for goal and player trackers to connect to, and the other to detect and receive event messages transmitted from the goal and player trackers. The event monitoring program 108 interacts with the RF transceivers 102 in the mobile computing device 105 to establish connections with the goal trackers 120 a-120 n and player trackers 140 a-140 n. A USB port 104 is provided to connect the mobile computing device 105 to other devices, such as memory sticks. In cases where the mobile computing device 105 may not be sold or distributed with a built-in RF transceiver, like RF transceiver 102, which is already cable of receiving and processing the radio signals transmitted from the goal trackers 120 a-120 n and the player trackers 140 a-140 n, a separate RF dongle 106 may be attached to a port (such as a USB port, a mini-USB port, or micro-USB port) on the mobile computing device 105, as already known in the art, in order to provide the radio frequency receiving capability.

The event monitoring program 108 also interacts with a set of data objects 109 configured to store a plurality of properties associated with the players, basketballs, goal trackers and player trackers being used by the system. The set of data objects 109, which may comprise a hierarchical database, a relational database or a collection of object-oriented data structures, for example, may also store values for player and/or team statistics, such as shot attempts, made shots, scores, steals, turnovers, etc. FIG. 22 shows a high-level block diagram illustrating by way of example some of the data objects that could be used in embodiments of the present invention to record, track and look up properties and values associated with the basketballs, the players, the teams, the wrist trackers, and the goal trackers, as well as player and team performance statistics.

The goal trackers 120 a-120 n and the player trackers 140 a-140 n are each equipped with a battery operated circuit board containing RF transceivers 124 and 144, respectively, for sending messages to the mobile computing device 105 over standard communication links typical in the art of two-way communication (BLE, WiFi, ANT, etc). The goal trackers 120 a-120 n and the player trackers 140 a-140 n also include digital processing units (DPUs) 124 and 144, respectively, comprising the central processing unit (CPU), RAM, and other components typical for microcontroller circuit boards.

In the embodiment of the basketball event monitoring system shown in FIG. 1, the sensing range of the RFID readers inside the goal trackers 120 a-120 n and player trackers 140 a-140 n is directly proportional to the signal power emitted and the size of the antenna in the readers. Because the player trackers 140 a-140 n with the RFID readers 142 are worn on each wrist of every player, preferably on the underside of each wrist, the ideal player trackers 140 a-140 n are fashioned to be as small as possible, thus limiting their ranges to about 12 inches. However, a 12-inch range is typically adequate for the sport of basketball because, except for the relatively short periods of time during which the ball is in flight toward a goal, or being dribbled, the basketball is almost constantly moving into and out of an area within 12-inches of one or more players' hands and wrists. It will be understood and appreciated by those skilled in the art that goal trackers and player trackers equipped with RFID readers having greater or lesser sensing ranges may be used without departing from the scope of the present invention.

FIG. 2 contains a schematic diagram showing the primary physical components of a printed circuit board 200 suitable for use inside the goal trackers 120 a-120 n and the player trackers 140 a-140 n for the embodiment of the present invention shown in FIG. 1. As shown in FIG. 2, the printed circuit board 200 houses a random access memory (RAM) chip 205 for storing data, a flash memory chip 210 containing application code to be executed by the micro CPU 235, other sensor chips 215, such as accelerometers and gyroscopes, for example, an RF communications module 225 for communicating with other devices via RF transmissions, an RFID reader 230 for activating passive RF emitters within a predetermined maximum distance from printed circuit board 200. The micro CPU 235 is a data processing unit that executes program instructions in the onboard application code against the data stored in the RAM 205 to carry out the critical processing functions of determining when an event has occurred and transmit the appropriate messages to the mobile computing device 105 in response to the occurrence of those certain events. All of these physical components communicate with each other over a bus 220, as is typical for a printed circuit board in the data processing and communications industry. Although not shown in FIGS. 1 and 2, the goal trackers 120 a-120 n and the player trackers 140 a-140 n are also each equipped with a battery to power all of the components. Ideally, the battery is rechargeable.

FIGS. 3A and 3B show two sides, respectively, of a basketball configured to operate in accordance with one embodiment of the present invention. As shown in FIGS. 3A and 3B, the basketball is equipped with eight ball tags, numbered 1-8. As stated previously, each ball tag includes one passive RFID emitter. The range of these passive RFID emitters in the ball tags is typically anywhere from a few centimeters to a meter or so, depending on the sizes of the antennas and strength of the signals emitted. In this example, the eight ball tags, and therefore eight passive RFID emitters, are attached to the basketball at four equidistant locations on each hemisphere of the basketball in order to increase the likelihood that at least one of the passive RFID emitters will always fall within the field of view of the RFID readers on the players' wrists while the players handle the basketball. It will be understood and appreciated by those skilled in the art, however, that embodiments of the present invention may use a different number of ball tags and may place those ball tags in different locations and orientations around or inside the basketball, depending on the ranges and strength of the RFID readers and passive RFID emitters used. FIG. 3C contains a schematic diagram illustrating the transmission signals and the distances between the RFID reader in the player tracking devices on the players' and referee's wrists and the passive RFID emitters in the ball tags for the exemplary basketball containing eight ball tags and eight passive RFID emitters.

FIG. 4 shows a high-level block diagram illustrating the components of a basketball event monitoring system according to a different embodiment of the present invention. The components in this embodiment are substantially identical to the components in the embodiment shown in FIG. 1 and described above, except that the ball tags 460 a-460 n attached to the basketballs (the basketballs are not shown) each include a data processing unit (DPU) 466 and an active RF transmitter 468, instead of a solitary passive RFID emitter 162 shown in FIG. 1. The data processing unit DPU 466 and the active RF transmitter 468 are configured to periodically broadcast a programmed identifier 464 (the RFID) to any listening RF transceiver within range of the ball. Like the goal trackers 420 a-420 n and player trackers 440 a-440 n, the components of the ball tags 460 a-460 n in FIG. 4 are all battery powered. (The batteries are not shown in FIG. 4.) Moreover, because the ball tags 460 a-460 n each have their own internal battery to use as a power source, the signal strength and transmission range for the active RF transmitter 468 are much greater than the signal strength and transmission range of the passive RFID emitters in the embodiment shown in FIG. 1. This greater signal strength and greater range permits the system to work effectively even when using a set of basketballs that have only a single ball tag in each basketball.

When a basketball with one of the ball tags 460 a-460 n is within range of one of the goal trackers 420 a-420 n, or within range of one of the player trackers 440 a-440 n, the RFID reader 426 in the goal tracker 420 a or the RFID reader 442 in the player tracker 440 a receives the unique ball identifier being constantly transmitted by the active RF transmitter 468 in the ball tag 460 a. The goal tracker 420 a or the player tracker 440 a will process the ball identifier to determine whether a new event (such as a shot-attempt or a change of possession) has occurred, and if so, transmit the ball identifier and the goal or player identifier to the mobile computing device 405 via the RF transceivers 424 and 444, where that information will be used by the event monitoring program 408 on the mobile computing device 405 to update and/or display the shooting or turnover statistics for the game. For the active system depicted in FIG. 4, the RFID readers 426 and 442 typically comprise secondary RFID transceivers configured to receive and decode the radio frequency signals transmitted from the active RF transmitters 468 in the ball tags 460 a-460 n in the basketballs.

FIG. 5A contains an illustration of the cross-section of a basketball 505 with a single ball tag 510 embedded therein. FIG. 5B contains a schematic diagram illustrating the location and ranging of the single ball tag 510 with the active RFID emitter and the RFID reader in the player tracker 515 when a player 520 holds the basketball 505. FIG. 6 shows an exemplary printed circuit board 600 for the goal trackers 420 a-420 n, player trackers 440 a-440 n and ball tags 460 a-460 n for the active RFID tag version of the ball possession and shot-tracking system of the present invention. As shown in FIG. 6, the printed circuit board 600 includes an RFID transceiver 630, instead of an RFID reader, which communicates the unique ball identifier to the RF transceivers in the goal trackers 420 a-420 n and the player trackers 440 a-440 n during a basketball game or other basketball activity.

FIGS. 7A and 7B contain illustrations showing the positions of two goal trackers attached to a basketball goal 705 in accordance with an embodiment of the present invention. As shown best in FIG. 7A, a far field goal tracker 710 is positioned above and behind the rim 715, and is configured to detect and decode the radio frequency signal containing the basketball identifier code transmitted by an active or passive RFID emitter attached to a basketball 720 that enters the hemispherical area represented by the circle 722 in FIG. 7A. When the far field goal tracker 710 detects that the basketball 720 is inside the hemispherical area represented by circle 722, the far field goal tracker 710 transmits a shot-attempt event message to the mobile computing device, along with the basketball 720's identification code and an identification code for the goal. The mobile computing device uses this information, in conjunction with the most recent ball possession event data transmitted from one or more of the player tracking devices, to determine which player took the shot, whereupon that player's shot-attempt total is suitably incremented.

As shown best in FIG. 7B, a near field tracker 750 is positioned in, on or near the net 730, underneath the rim 715, and is configured to detect and decode the radio frequency signal containing the basketball identifier code transmitted by an active or passive RFID emitter attached to another basketball 760 if the basketball 760 enters the hemispherical area represented by the circle 770 in FIG. 7B, the space roughly approximating the cylindrical volume of the net 730. When the near field goal tracker 750 detects that the basketball 760 is inside the hemispherical area represented by circle 770, the near field goal tracker 760 transmits a made-shot event message to the mobile computing device, along with basketball 760's identification code and the identification code for the goal. The mobile computing device uses this information, in conjunction with the most recent ball possession event data transmitted from one or more of the player tracking devices, to determine which player took the shot, whereupon that player's made-shot total is suitably incremented. If the far field goal tracker 710 detects the presence of a basketball inside the hemispherical area represented by the circle 722 without the near field goal tracker 750 detecting the presence of the same basketball within the hemispherical area represented by the circle 770 very soon thereafter, then it can be assumed that the basketball bounced off of the rim 715 and/or backboard 725 without the basketball 720 passing through the net 730 (i.e., a missed shot event occurred).

The purpose of FIG. 8 is to illustrate and help describe the interaction between the ball tags, the player trackers, the goal trackers and the event monitoring program 810 stored in the memory 815 of the mobile computing device 805 and executed by microprocessor 820 in the present invention. In particular, FIG. 8 illustrates one scenario in which three players, P1, P2 and P3 are shooting three different basketballs RB1, RB2 and RB3 on one end of a basketball court having one basketball goal with two goal trackers RG1 and RG2 attached thereto. The two goal trackers RG1 and RG2 include far and near field RFID readers capable of reading passive RFID or active RF transceiver signals. Each player P1, P2 and P3 wears an RFID reader RP1 and RP2 (one on each wrist), which are capable of reading passive RFID or active RF Transceiver signals and outputting the ball ID to the data processing unit in the trackers. Each ball is either the passive RFID or active RF transceiver ball. One or both of the player worn wrist trackers RP1 and RP1′ detects when the player P1 is in possession of the ball RB1, where possession means one or both hands have touched the ball for a period of at least 0.25 seconds. One or both of the trackers RP1 or RP1′ will read the unique identifier transmitted from the ball tag in RB1. When this happens, one or both of the player trackers RP1 and RP1′ transmits a message to the event monitoring program 810 on the mobile computing device 805 notifying the event monitoring program 810 that the player P1 has possession of the ball RB1. The message is sent via an RF transmission typical in the art of two-way communications.

If player P1 shoots the ball RB1 toward the hoop, the far-field goal tracker RG1 will read the unique identifier of the ball and send a message to the mobile computing device 805 indicating the ball came close to the hoop and a shot-attempt has occurred. If the ball RB1 comes within range of the near field goal tracker RG2, then the near field goal tracker RG2 will transmit a made shot event message to the possession and shot-tracking application 810 on the mobile computing device 805. Similar messages are sent for players P2 and P3 when their wrist-worn player tracking devices RP2, RP2′, RP3 and RP3′ detect that player P2 is in possession of ball RB2 and player P3 is in possession of ball RB3. Although not shown in FIG. 8, the system can accommodate and process the data associated with a multiplicity of additional basketballs, basketball goals, goal trackers and wrist-worn player trackers, all being used substantially simultaneously, detecting basketballs and events, and sending event messages to the mobile computing device 805 in real-time.

The programs running on the microprocessors and data processing units in both the active RFID system and passive RFID systems of the present invention operate in substantially the same manner, except for the interface to the trackers. In the passive RFID system, the passive RFID emitters in the basketballs communicate ball identifiers to an RFID reader module located in the goal trackers and the player trackers. In the active RFID system, the RF transceivers in the basketballs communicate the ball identifiers to the RFID transceivers in the goal trackers and the player trackers. In the passive RFID system, the ball tag in the basketball contains no programmed instructions and no data processors, while in the active system, the ball tag contains a power source (battery) and programmed instructions that cause the data processor in the ball tag to periodically transmit a programmed ball identifier to the trackers.

FIG. 9 is a high-level flow diagram illustrating an exemplary algorithm for a program executed by the data processing unit in the active RFID basketball in one embodiment of the present invention. The program may be embodied in software instructions, firmware instructions, or hardware, or a combination of software instructions, firmware instructions and hardware. First, the program is activated by a hardware interrupt generated by the on-board accelerometer on a circuit board embedded in the basketball. This accelerometer is preset to activate the interrupt when the acceleration experienced by the basketball exceeds a 2 G force (twice the force of gravity). This acceleration force is referred to as “bounce to wake” acceleration because it is generally produced by bouncing the basketball on the floor or the ground. Although the bounce to wake acceleration is 2 G in this example, it will be understood and appreciated by skilled artisans that other acceleration values, greater or less than 2G, could be used to wake the program without departing from the scope of the claimed invention. Once this interrupt is generated to activate the system, the circuit board is powered on and the peak acceleration variable PEAKACCEL is reset to zero. See steps 904 and 906 in FIG. 9. Next, the program enters a looping sequence of operations bounded by steps 908 and 938 in FIG. 9.

The first operation inside the loop marked by step 908 is to read the absolute acceleration from the accelerometer and save this value to memory (see steps 910 and 912). This is followed by a test, at step 914, to see if the absolute acceleration is greater than the current peak acceleration (PEAKACCEL). If the absolute acceleration is greater than PEAKACCEL, then PEAKACCEL is reset to this new acceleration in steps 916 and 918. Next, at step 920, the program gets the uptime (number of minutes the software has been running since the last check) and, if this uptime is less than 15 minutes, then the program uses the RF transceiver to transmit the ball identifier (or RFID) of the ball over the radio for any listening transceiver within range to receive. See step 934. The software then performs a 10 ms sleep and repeats the loop by returning to step 908. If the uptime is found to be more than 15 minutes in step 922, then the stored absolute peak acceleration (PEAKACCEL) is compared to 2G (step 924). If the peak acceleration over the last 15 minutes is greater than 2G, then the program clears the peak acceleration variable in steps 928 and 930, resets the uptime variable to time 0 (step 932), and in step 934, sends the ball identification over the transceiver as before. If the peak acceleration over the last 15 minutes is less than 2G, then the program resets the system by turning the power off (step 926) going into a low power-consumption mode to wait for the next hardware interrupt from a 2G “bounce-to-wake” acceleration to start the entire process over again.

FIG. 10 is a high-level flow diagram illustrating by way of example an algorithm for a program executed by the data processing unit in the player trackers worn on the players' wrists in one embodiment of the present invention. The program may be embodied in software instructions, firmware instructions, or hardware, or a combination of software instructions, firmware instructions and hardware. The program begins after the sensor board receives a hardware interrupt enabling power. In one embodiment, this hardware interrupt is enabled via a 2G acceleration sensed by an on-board accelerometer, while in other embodiments the interrupt may be generated when the player presses a button on the outside of the tracker. When the program starts, the first step, step 1002 is to spawn a separate thread of execution (shown in FIG. 20 and discussed in more detail below) that tests the peak acceleration of the device and checks for network “stop” messages—both of which will cause the program to terminate and put the device into low-power sleep mode. Next, the program enters the loop bound by steps 1006 and 1030, where the program carries out steps to detect when a ball is in the possession of the player wearing this particular tracking device and sends a message to the mobile computing device that the player has a ball and which ball the player has.

After entering the loop at step 1006, the program tests to see if a connection to the mobile computing device network (WiFi, BLE, ANT, etc.) is available (see step 1008). If the connection is not available, the program sleeps for 1 second (step 1012) and execution returns to the beginning of the loop (step 1006) so that the availability of the network can be tested in step 1008 again. If the connection to the network is available, then the program waits for an RFID interrupt event to occur (step 1014). This interrupt could be generated by a passive RFID Reader hardware interrupt event indicating that a ball with a passive RFID emitter is in range, or a RF Transceiver interrupt event indicating that a ball with an active RFID transceiver is in range. When one of these interrupts is received, the program obtains the identifier for the ball and saves the identifier and the event data to memory (step 1016).

Next, at step 1018, the STOP_FLAG variable is tested to see if the program should terminate and put the tracker into low power mode. If the STOP_FLAG variable is not set, then the program uses the RF radio in the tracker to send a message to the mobile computing device indicating that the player wearing the tracker is in possession of the identified ball. See step 1020. This message, which includes an identifier for the player's wrist tracker and the ball identifier, is sent using an RF transmission signal common in the art. After the message is sent, the program enters a ball possession loop (step 1022 of FIG. 10), where it will stay until the program detects that the ball is no longer in the player's possession. The steps that the program executes while the player still has the ball and the program is executing inside the ball possession loop are shown in FIG. 11, which is described in more detail below. Continuing with the description of FIG. 10, however, when the program returns from the ball possession loop shown in FIG. 11, it means that the program has determined that the player has lost possession of the ball. Therefore, at step 1024, the program sends a message to the mobile computing device indicating that the player has lost possession of the ball, and resets the ball identifier BALL RFID to null (steps 1026 and 1028). At this point, program execution returns again to the beginning of the loop marked by step 1006, to again carry out steps to detect when the player wearing this particular player tracking device gains possession of a ball.

FIG. 11 shows a high-level flow diagram illustrating by way of example an algorithm for the “ball possession loop,” executed by the program running on the player tracker. The ball possession loop, which is bounded by steps 1102 and 1118 in FIG. 11, is entered when the program determines that the player has gained possession of a particular basketball and is repeatedly executed by the program until the player loses possession of that particular basketball. The ball possession loop begins by sleeping for 100 ms (step 1104), followed by retrieving the RFID from the passive RFID emitter or the active RFID transceiver in the ball tag (step 1106) to see if a ball is detected. If a ball is detected, the identifier for the ball is stored in the variable BALLRFID_NEW. See step 1108. Next, at step 1110, the STOP_FLAG variable is tested to see if the program has been commanded to terminate (by, for example, the user pressing a button on the player tracker to shut it down). If the STOP_FLAG is not set, the BALLRFID_NEW is compared with the previous BALLRFID (step 1112) to see if the player is still in possession of the same ball previously identified in step 1016 of FIG. 10. If the ball identifier is the same, then program execution returns to the beginning of the ball possession loop (step 1102) to pause another 100 ms. If BALLRFID_NEW is not the same as the previous BALLRFID, and if BALLRFID_NEW is not empty (NULL), indicating that no ball is in range of the player tracker, then program execution returns to step 1014 of FIG. 10 by way of flow chart connector FC1 to wait for another ball to come within range of the player tracker.

On the other hand, if the BALLRFID_NEW is empty or NULL, then the program next tests to see if three seconds have elapsed with the RFID reader returning an empty or NULL ball identifier. See step 1116. If three seconds has not elapsed, then the ball possession loop is repeated to determine whether the ball comes back into range of the player tracker. If three seconds has elapsed, then the ball with the identifier saved in BALLRFID is assumed to no longer be in possession of the player. At this point the program leaves the ball possession loop and picks up again at step 1024 of FIG. 10, where the program sends a “lost possession” event message to the mobile computing device.

FIG. 12 is a high-level flow diagram showing by way of example one algorithm for a program running on the microprocessor of the far field goal tracker to detect shot attempts in an embodiment of the present invention. A far-field goal tracker with an RFID reader is mounted on the hoop or backboard to detect shot-attempts as a ball enters the field of view of the RFID reader. The RFID reader then outputs a signal used by the data processing unit in the goal tracker to determine that a shot-attempt has occurred. As shown in FIG. 12, the program begins upon receiving a power-on interrupt from an onboard accelerometer that is preset to activate the interrupt when the accelerometer experiences an acceleration greater than 1G. This 1 G acceleration is referred to as the “shoot to wake” acceleration because a player must shoot a basketball at the goal to shake the goal, thereby causing an acceleration event greater than 1 G. Although the shoot to wake acceleration is 1 G in this example, it will be understood and appreciated by skilled artisans that other acceleration values, greater or less than 1 G, could be used to wake the program without departing from the scope of the claimed invention. After this power-on interrupt is received, the far field goal tracker receives power and the data processing unit starts executing the program. The first step in the program, step 1204, is to spawn a separate thread of execution (shown in FIG. 21 and described in more detail below) that waits for little to no movement of the goal over a 15-minute period, or for a network “stop” message to set the STOP_FLAG to terminate the program.

Next, the program enters the loop bounded by steps 1206 and 1222, where the program checks for ball RFID identities and transmits those identities to the mobile computing device. Upon entering the loop, the program first tests to ensure that it can communicate with the mobile computing device's network. See step 1208. If there is no connection to the network, and if the STOP_FLAG is not enabled, the program sleeps for 1 second before returning to the beginning of the loop. Steps 1210, 1212 and 1204. If the connection to the mobile computing device is available, then, at step 1214, the program waits for an RFID interrupt indicating that a ball is in range of the far field goal tracker, or for the STOP_FLAG to become set. If the interrupt is received, then the BALLRFID returned is saved in memory and the STOP_FLAG is tested to make sure the program has not been requested to terminate. Step 1218. If the STOP_FLAG is not set, then the program uses the RF radio to send a message over the mobile computing device's network to notify the basketball possession and shot-tracking mobile app that a shot-attempt has occurred for the given BALLRFID. After the message is sent, the main loop is repeated, thereby causing the program to again check for a connection to the mobile computing device and wait for the next RFID event to occur or to terminate the app if the STOP_FLAG is set. Steps 1222 and 1206.

FIG. 13 is a high level flow diagram illustrating by way of example one algorithm for a program running on the near field goal tracker to detect made shots. This near-field goal tracker with an onboard RFID reader is mounted on the hoop or net to detect made shots as a ball enters the field of view of the RFID reader oriented to detect basketballs inside the zone of the net. As shown in FIG. 13, this program begins after receiving a power-on interrupt from the onboard accelerometer that is preset to activate the interrupt when the accelerometer experiences an acceleration greater than 1 G. This 1 G acceleration is referenced as a “shoot to wake” acceleration because a player must shoot a ball at the goal, thereby causing an acceleration event greater than 1 G in the near field goal tracker. Again, although the shoot to wake acceleration is 1 G in this example, it will be understood and appreciated by skilled artisans that other acceleration values, greater or less than 1 G, could be used to wake the program without departing from the scope of the claimed invention. After the power-on interrupt is received, the components of the near field goal tracker receive power and the program starts. The first step in the program, step 1304, is to spawn a separate thread of execution (shown in FIG. 21 and described in more detail below) that waits for little to no movement over a 15-minute period, or for a network “stop” message to set the STOP_FLAG to terminate the firmware (described above).

Next, the program enters a loop bounded by steps 1306 and 1322, which checks ball RFID identities and transmits those identities to the mobile computing device. Upon entering the loop, the program tests to ensure that it can communicate with the mobile computing device's local network. See step 1308. If no connection is available, and the STOP_FLAG is not enabled, then the program sleeps for 1 second and then execution returns to the beginning of the loop marked by step 1304. See steps 1310 and 1312. If the connection to the mobile computing device is available, then the program waits for an RFID interrupt (step 1314) indicating a ball is in range of the RFID Reader. When the interrupt is received, the program saves the identifier for the ball BALLRFID in memory (step 1316). Next, at step 1318, the STOP_FLAG is tested to make sure the program should not terminate. If the STOP_FLAG is not set, then the program uses the RF radio to send a message to the mobile computing device to notify the event monitoring program running on the mobile computing device that a made shot event has occurred for the goal and the given ball (based on the BALLRFID). After the message is sent, the main loop is repeated.

The event monitoring program running on the mobile computing device interacts with the RF radios on the mobile computing device to establish WiFi, Ant, BLE, or other RF data transmission connections with the goal trackers and player trackers, and to process event messages transmitted by the goal and player trackers. The event monitoring program running on the mobile computing device will now be described in more detail with reference to FIGS. 14 and 15.

The application is typically, although not necessarily, a multithreaded application having two primary threads of operation: The primary functions of the first thread, represented by the algorithm in FIG. 14, are to establish or permit asynchronous connections from the goal and player tracker radios, to establish a local mobile network for the goal and player trackers to connect to; and to detect and enumerate the goal and player trackers that are currently broadcasting events and identifiers, and send incoming event messages to the message processing thread. The primary function of the second thread, represented by the algorithm in FIG. 15, is to process event messages received from the goal and player trackers.

FIG. 14 is a high-level flow diagram showing by way of example one algorithm for the first thread of the event monitoring program running on the mobile computing device in an embodiment of the present invention. As shown in FIG. 14, when the thread starts, the first step, at step 1402, is to connect the RF radio of the mobile computing device directly to the radios on the goal and player trackers, or to connect the RF radio to a local network being used by the goal and player trackers. Next, the thread enters the loop bounded by steps 1404 and 1418, which loop causes the application thread to detect trackers and read incoming messages. At step 1406 inside the loop, the application thread identifies and enumerates all of the trackers currently connected and broadcasting events, and saves the identifiers for those trackers to a local variable list. Then, in steps 1410 and 1412, the application thread reads an incoming event message from the RF Radio and sends the message contents to the main message processing thread for further processing. Next, at step 1414, the application thread tests to see if the ENDAPP (end application) flag has been set. If the ENDAPP flag has not been set, then execution of the application thread returns to step 1404 in FIG. 14 to repeat the steps of detecting and enumerating trackers and reading incoming events from the RF radio. If the ENDAPP flag is set, because the user terminated the main processing thread of the application, for instance, then the thread disconnects from the mobile device network or from each connected tracker (step 1416) and execution of this thread ends.

FIG. 15 is a high-level flow diagram showing by way of example one algorithm for the main processing thread of the event monitoring program running on the mobile computing device in an embodiment of the present invention. The purpose of the main processing thread is to process messages and events transmitted to the mobile computing device from the goal and player tracking devices. As shown in FIG. 15, the message processing thread begins by entering a loop bounded by steps 1501 and 1526 of FIG. 15, which, generally speaking, comprises waiting for a message in the main message loop and processes that message. Thus, after entering the loop at step 1501, this thread waits for a message from the thread represented by FIG. 14 indicating that an RFID event has occurred. See step 1504. When the RFID event message is received, the thread reads that message information and determines which type of event was received, as shown at step 1506.

If the event received by the thread is a GOTPOSSESSION event received from a player tracker, the thread passes this event information to a PLAYER ACQUIRE BALL module, as shown in steps 1508 and 1516, for further processing. If the message is a LOSTPOSSESSION event received from a player tracker, then the thread passes this event information to the PLAYER LOST BALL module, as shown in steps 1510 and 1518. Likewise, if the message received is a SHOTATTEMPT or SHOTMADE event, then the thread passes the message data to the NET SHOT ATTEMPT or the NET SHOT MADE modules, respectively, depicted in FIG. 15 as steps 1512, 1520, 1514 and 1522. The algorithms for the aforementioned message processing modules, PLAYER ACQUIRE BALL, PLAYER LOST BALL, NET SHOT ATTEMPT and NET SHOT MADE, are shown in FIGS. 16-19 and described in more detail below. After the message processing thread finishes processing the message, the thread next tests in step 1524 to see if the user has requested to quit the application. If the user has not requested the application to end, then execution of this thread returns to step 1501 to repeat the message processing steps again. If the user has requested to quit the application, then the ENDAPP flag is set in step 1528 and the thread terminates.

FIG. 16 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a player tracker sends a message indicating that a player has gained possession of a basketball with either an active or a passive RFID emitter. This algorithm is typically carried out by the PLAYER AQUIRE BALL module mentioned at step 1516 of FIG. 15. The module starts at step 1602 by checking to see if the ball identified by the ball identifier in the message has already been identified as being in the possession of another player. If the ball has been assigned to another player, then the module may be configured to unassign the ball from that other player before performing additional team and/or game logic to account for the change of possession. See steps 1606 and 1608 in FIG. 16. For example, depending on the identifiers for the two players involved, the module may record that the change of possession was a steal if the players are on different teams, or a pass if the players are playing for the same team. Likewise, if the change of possession was a steal, the module may also be configured to increment a running total of turnovers for the player and his or her team. After team and game logic processing is complete, the module assigns the ball identified by the ball identifier to the player identified by the player identifier in the message. At this point, processing by this module comes to an end.

FIG. 17 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a player tracker sends a message indicating that a player has lost possession of a basketball with either an active or a passive RFID emitter. This algorithm is typically carried out by the PLAYER LOST BALL module mentioned at step 1518 of FIG. 15. As shown in FIG. 17, this module carries out team and/or game logic associated with a player losing possession of the ball, such as incrementing a counter tracking the total number of turnovers for the player and his or her team.

FIG. 18 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a goal tracker sends a message indicating that a shot attempt has occurred using a basketball having either an active or a passive RFID emitter. This algorithm is typically carried out by the NET SHOT ATTEMPT module mentioned at step 1520 of FIG. 15. More particularly, this module will be executed when a far-field goal tracker detects that a ball with an active or passive RFID emitter has passed into its field of view. The module starts, at step 1802 by testing to see if the ball has been identified as being in the possession of a particular player. If the module finds that the ball is currently assigned to a particular player (based on a player identifier) then the module increments the shot attempt count for that player and timestamps the shot attempt to memorialize when the shot attempt occurred. See step 1804. The module may also be configured to display the shot attempt information on a display screen on the mobile computing device in several ways typical in the art of a graphical application. The module may also be configured to send this shot attempt information to a cloud-based server if configured to do so. Finally, in step 1806, the module un-assigns the ball identifier from the player identifier and then execution of the module ends.

FIG. 19 is a high-level flow diagram illustrating by way of example one algorithm executed by the event monitoring program running on the mobile computing device when a goal tracker sends a message indicating that a made shot event has occurred using a basketball having either an active or a passive RFID emitter. This algorithm is typically carried out by the NET SHOT MADE module mentioned at step 1522 of FIG. 15. More particularly, this module will be executed when a near-field goal tracker detects that a ball with an active or passive RFID emitter has passed into its field of view, meaning that the ball has passed through the rim and the net. As shown in FIG. 19, the module starts at step 1910 by testing to see if the system has registered a shot attempt for the same ball and the same player within the last second. If an attempt has been registered in the last 1 second for the same player using the same ball, then the module increments the made shot count for that player, and also may display this made shot information on a display screen associated with the mobile computing device using any one of a variety of graphical display techniques known in the industry. The module may also send the made shot information to a cloud-based server if configured to do so. The module ends after the “made shot” information is recorded, displayed and/or transmitted.

FIG. 20 is a high-level flow diagram illustrating by way of example one algorithm that could be executed by a program thread running on the player trackers worn on the players' wrists in one embodiment of the present invention, wherein the function of the program thread is to determine whether the primary program thread running on the player tracker should terminate. This program thread, which runs separately from the primary thread on the player tracker, checks recent acceleration values for the player tracker and also determines whether any network “stop” messages have been received. As shown in FIG. 20, the thread begins, at steps 2004 and 2006, by reading the instantaneous acceleration from an accelerometer sensor associated with the player tracker. If this acceleration is greater than the peak acceleration (PEAKACCEL) then the thread stores the new acceleration value as the PEAKACCEL value, as indicated in steps 2008 and 2010.

Next, at steps 2012 and 2014, the system “up-time” is retrieved and examined to determine whether the system has been up for at least 15 minutes. If the up-time is less than 15 minutes, then the thread retrieves any network messages received on the radio, as indicated in step 2026, and looks to see if a STOP message has been received (step 2030). If a STOP message has not been received, then the program sleeps for 100 ms and execution returns to step 2004. If the outcome of the up-time check in step 2014 indicates that the system has been up for at least 15 minutes, then the PEAKACCEL is tested against a 2.0 G acceleration in step 2016. If the PEAKACCEL is less than 2.0 G then the STOP_FLAG is set to true (at step 2018) and the thread terminates. However, if the PEAKACCEL is greater than 2.0 G, then the PEAKACCEL variable is reset to zero and the UPTIME variable is reset to time 0 (starting the 15 minute clock over), as shown in steps 2020, 2022 and 2024. Next, at step 2026 and 2030, the network messages are retrieved and tested to see if a STOP message has been received. If the STOP message has been received, then the STOP_FLAG is set to true (at step 2032) and the thread terminates. On the other hand, if the STOP message has not been received, the tread waits for 100 ms (at step 2034) and execution returns to step 2004 to read the instantaneous acceleration again and test the acceleration against the current value for the PEAKACCEL. Although the up-time and the PEAKACCEL values used in this example are 15 minutes and 2.0 G, respectively, it will be understood and appreciated by skilled artisans that other up-time and PEAKACCEL values, greater or lower than the given examples above, could be used without departing from the scope of the claimed invention.

FIG. 21 is a high-level flow diagram illustrating by way of example one algorithm for the “waiting for stop” thread spawned at step 1204 of FIG. 12 to determine whether the primary thread being executed on the far field goal tracker should terminate. As shown in FIG. 21, the thread begins, at steps 2104 and 2106, by reading the instantaneous acceleration from an accelerometer sensor associated with the far field goal tracker. If this acceleration is greater than the peak acceleration (PEAKACCEL) then the thread stores the new acceleration value as the PEAKACCEL value, as indicated in steps 2108 and 2110. Next, at steps 2112 and 2114, the system “up-time” is retrieved and examined to determine whether the system has been up for at least 15 minutes. If the up-time is less than 15 minutes, then the thread retrieves any network messages received on the radio, as indicated in step 2126, and looks to see if a STOP message has been received (step 2130). If a STOP message has not been received, then the program sleeps for 100 ms and execution returns to step 2104. If the outcome of the up-time check in step 2114 indicates that the system has been up for at least 15 minutes, then the PEAKACCEL is tested against a 0.25 G acceleration in step 2116. If the PEAKACCEL is less than 0.25 G then the STOP_FLAG is set to true (at step 2118) and the thread terminates. However, if the PEAKACCEL is greater than 0.25 G, then the PEAKACCEL variable is reset to zero and the UPTIME variable is reset to time 0 (starting the 15 minute clock over), as shown in steps 2120, 2122 and 2124. Next, at step 2126 and 2130, the network messages are retrieved and tested to see if a STOP message has been received. If the STOP message has been received, then the STOP_FLAG is set to true (at step 2132) and the thread terminates. On the other hand, if the STOP message has not been received, the tread waits for 100 ms (at step 2134) and execution returns to step 2104 to read the instantaneous acceleration again and test the acceleration against the current value for the PEAKACCEL. Although the up-time and the PEAKACCEL values used in this example are 15 minutes and 0.25 G, respectively, it will be understood and appreciated by skilled artisans that other up-time and PEAKACCEL values, greater or lower than the given examples above, could be used without departing from the scope of the claimed invention.

FIG. 22 is a high-level block diagram illustrating by way of example some of the data objects that could be used in embodiments of the present invention to record, track and look up properties and values associated with the basketballs, the players, the teams, the wrist trackers, and the goal trackers, as well as player and team performance statistics, like shot-attempts, made shots, steals and turnovers.

The above-described preferred embodiments are intended to illustrate the principles of the invention, but not to limit its scope. Various other embodiments, modifications and equivalents to these preferred embodiments may occur to those skilled in the art upon reading the present disclosure or practicing the claimed invention. Such variations, modifications and equivalents are intended to come within the scope of the invention and the appended claims. 

What is claimed is:
 1. A real-time event monitoring system for a basketball-related activity involving basketball goat, a plurality of players, and a basketball equipped with an RFID tag configured to transmit a radio frequency signal encoded with a ball ID for the basketball, the real-time event monitoring system comprising: a) a mobile computing device comprising a wireless communications interface, a microprocessor, a memory, an event monitoring program stored in the memory, and a set of data objects stored in the memory, the set of data objects arranged to store for each player in the plurality of players, a player ID, a player tracker ID, a ball ID and a player performance statistic; b) a plurality of player tracking devices configured to be worn by the plurality of players, respectively, each player tracking device including a player radio frequency transceiver for wireless communication with the mobile computing device, a player RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag on the basketball if the basketball is in reading range of the player RFID reader, and a player data processing unit programmed to (i) determine that the player wearing the player tracking device has gained or lost possession of the basketball based on an output from the player RFID reader, and (ii) transmit a possession change event message to the mobile computing device via the player radio frequency transceiver indicating that the player has gained or lost possession of the basketball, the possession change event message including the player ID for the player, the ball ID and a possession change event type; and c) a goal tracking device, configured for attachment to the basketball goal, the goal tracking device comprising a goal radio frequency transceiver for wireless communication with the mobile computing device, a goal RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag of the basketball if the basketball is in reading range of the goal RFID reader, and a goal data processing unit programmed to (i) determine that a shot has been taken based on an output from the goal RFID reader, and (ii) transmit a shot event message to the mobile computing device via the goal radio frequency transceiver, the shot event message indicating that the shot has been taken and including the goal ID and the ball ID; d) wherein the event monitoring program on the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor (i) to determine which player in the plurality of players shot the basketball on the basketball goal based on the possession change event message, the shot event message, and one or more values stored in the set of data objects in the memory, and (ii) to record a change in the player performance statistic for the player who shot the basketball.
 2. The event monitoring system of claim 1, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's wrist.
 3. The event monitoring system of claim 1, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's shoe.
 4. The event monitoring system of claim 1, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's upper arm, or chest, or leg or abdomen.
 5. The event monitoring system of claim 1, wherein the RFID tag in the basketball is a passive RFID tag configured to transmit the radio frequency signal encoded with a ball ID in response to being interrogated by the RFID reader in the player tracker device.
 6. The event monitoring system of claim 1, wherein the RFID tag in the basketball is an active RFID tag configured to periodically transmit the ball ID to any listening RFID reader without first being interrogated by an RFID reader.
 7. The event monitoring system of claim 1, wherein: the basketball goal comprises a rim and a net; and b) the goal RFID reader is attached to the basketball goal so that the basketball will pass into the reading range of the goal RFID reader when the basketball passes through the rim and the net.
 8. The event monitoring system of claim 7, wherein: a) the player performance statistic stored in the data object is a scoring total for each player; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to increment the scoring total for the player who shot the basketball.
 9. The event monitoring system of claim 1, wherein: a) the basketball goal comprises a backboard, a rim and a net; and b) the goal RFID reader is attached to the basketball goal so that the basketball will pass into the reading range of the goal RFID reader when the basketball strikes the backboard, the rim or the net.
 10. The event monitoring system of claim 9, wherein: a) the player performance statistic stored in the data object is a shot-attempt count for each player; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to increment the shot-attempt count for the player who shot the basketball.
 11. The event monitoring system of claim 1, wherein: a) the mobile computing device further comprises a display screen; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to display the change in the player performance statistic on the display screen in real-time.
 12. The event monitoring system of claim 1, wherein: a) the mobile computing device further comprises a network adapter for establishing a data communications channel to a cloud-based server; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine that the data communications channel is currently available, and to transmit the change in the player performance statistic to the cloud-based server over the data communications channel.
 13. The event monitoring system of claim 1, wherein the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values stored in the set of data objects, that one player in the plurality of players has lost possession of the basketball to another player.
 14. The event monitoring system of claim 1, wherein the event monitoring program in the memory of the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values in the set of data objects, that one player in the plurality of players has passed possession of the basketball to another player.
 15. The event monitoring system of claim 1, wherein the event monitoring program in the memory of the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values in the set of data objects, that one player in the plurality of players has taken possession of the basketball from another player.
 16. The event monitoring system of claim wherein the event monitoring program on the mobile computing device comprises program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type, the shot event message, and said one or more values in the set of data objects, that one player in the plurality of players has assisted a made shot taken by another player with the basketball.
 17. The event monitoring system of claim 1, wherein the event monitoring program on the mobile computing device comprises program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type, the shot event message, and said one or more values in the set of data objects, that one player in the plurality of players has collected a rebound of the basketball after a missed shot on the basketball goal.
 18. The event monitoring system of claim 1, wherein: a) the basketball-related activity involves at least two basketball teams and at least two basketball goals, each basketball goal being equipped with at least one goal tracking device, said at least one goal tracking device comprising a goal radio frequency transceiver for wireless communication with the mobile computing device, a goal RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag of the basketball if the basketball is in reading range of the goal RFID reader, and a goal data processing unit programmed to (i) deter that a shot has been taken based on an output from the goal RFID reader, and (ii) transmit a shot event message to the mobile computing device via the goal radio frequency transceiver, the shot event message indicating that the shot has been taken and including the goal ID and the ball ID; and b) the set of data objects in the memory is further arranged to store a team ID for each player in the plurality of players, and a team statistic for each basketball team in the at least two basketball teams; c) wherein the event monitoring program on the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor (i) to determine, based on the possession change event message, the shot event message, and said one or more values stored in the set of data objects in the memory, which team the player who shot the basketball on the basketball goal plays for, and (ii) to record a change in the team statistic for the basketball team of the player who shot the basketball.
 19. The event monitoring system of claim 18, wherein: a) the team statistic stored in the data object is a scoring total for the basketball team of the player who shot the basketball; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to increment the scoring total for the basketball team of the player who shot the basketball.
 20. The event monitoring system of claim 19, wherein: a) the mobile computing device further comprises a wireless data communications link to a scoreboard configured to display the scoring total for the basketball team of the player who shot the basketball; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to transmit the incremented scoring total for the basketball team of the player who shot the basketball to the scoreboard using the wireless data communications link.
 21. The event monitoring system of claim 18, wherein: a) the team statistic stored in the data object is a shot-attempt count for the basketball team of the player who shot the basketball; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to increment the shot attempt count for the basketball team of the player who shot the basketball.
 22. The event monitoring system of claim 18, wherein the event monitoring program on the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor (i) to determine, based on the possession change event message, the shot event message, and said one or more values stored in the set of data objects in the memory, that a player on one of the at least two basketball teams has taken possession of the basketball away from a player on another of the at least two basketball teams, and (ii) to record a change in the team statistics for at least one of the at least two basketball teams.
 23. The event monitoring system of claim 1, further comprising a referee tracking device configured to be worn by a referee involved in the basketball-related activity, the referee tracking device including a referee radio frequency transceiver for wireless communication with the mobile computing device, a referee RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag on the basketball whenever the basketball is in reading range of the referee RFID reader, and a referee data processing unit programmed to (i) determine that the referee wearing the referee tracking device has gained or lost possession of the basketball based on an output from the referee RFID reader, and (ii) transmit a game stoppage event message to the mobile computing device via the referee radio frequency transceiver, the game stoppage event message including a referee ID for the referee and the ball ID.
 24. The event monitoring system of claim 1, wherein each player RFID reader and each goal RFID reader comprises a secondary RF transceiver.
 25. A real-time event monitoring system for a basketball-related activity involving a basketball goal, a plurality of players, and a basketball equipped with an RFID tag configured to transmit a radio frequency signal encoded with a ball ID for the basketball, the real-time event monitoring system comprising: a) a mobile computing device comprising a wireless communications interface, a microprocessor, a memory, an event monitoring program stored in the memory, and a set of data objects stored in the memory, the set of data objects arranged to store for each player in the plurality of players, a player ID, a player tracker ID, a ball ID and a player performance statistic; b) a plurality of player tracking devices configured to be worn by the plurality of players, respectively, each player tracking device including a player radio frequency transceiver for wireless communication with the mobile computing device, a player RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag on the basketball whenever the basketball is in reading range of the player RFID reader, and a player data processing unit programmed to (i) determine that the player wearing the player tracking device has gained or lost possession of the basketball based on an output from the player RFID reader, and (ii) transmit a possession change event message to the mobile computing device via the player radio frequency transceiver indicating that the player has gained or lost possession of the basketball, the possession change event message including the player ID for the player, the ball ID and a possession change event type; and c) a goal tracking device, configured for attachment to the basketball goal, the goal tracking device comprising a goal radio frequency transceiver for wireless communication with the mobile computing device, a goal RFID reader configured to detect and decode the radio frequency signal transmitted by the RFID tag of the basketball whenever the basketball is in reading range of the goal RFID reader, and a goal data processing unit, programmed to transmit a shot event message to the mobile computing device via the goal radio frequency transceiver whenever the goal RFID reader succeeds in detecting and decoding the radio frequency signal transmitted by the RFID tag of the basketball, the shot event message including the goal ID and the ball ID; d) wherein, when the mobile computing device has not received a shot event message within a predetermined time period after receiving a possession change event message, the event monitoring program on the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor (i) to determine which player in the plurality of players gained or lost possession of the basketball based on the possession change event message and one or more values stored in the set of data objects in the memory, and (ii) to record a change in the player performance statistic for the player who gained or lost possession of the basketball.
 26. The event monitoring system of claim 25, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's wrist.
 27. The event monitoring system of claim 25, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's shoe.
 28. The event monitoring system of claim 25, wherein each player tracking device in the plurality of player tracking devices is configured to be worn on the player's upper arm, or chest, or leg or abdomen.
 29. The event monitoring system of claim 25, wherein the RFID tag in the basketball is a passive RFID tag configured to transmit the radio frequency signal encoded with a ball ID in response to being interrogated by the RFID reader in the player tracker device.
 30. The event monitoring system of claim 25, wherein the RFID tag in the basketball is an active RFID tag configured to periodically transmit the ball ID to any listening RFID reader without first being interrogated by an RFID reader.
 31. The event monitoring system of claim 25, wherein: a) the basketball goal comprises a rim and a net; and b) the goal RFID reader is attached to the basketball goal so that the basketball will pass into the reading range of the goal RFID reader when the basketball passes through the rim and the net.
 32. The event monitoring system of claim 25, wherein: c) the mobile computing device further comprises a display screen; and d) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to display the change in the player performance statistic on the display screen in real-time.
 33. The event monitoring system of claim 25, wherein: a) the mobile computing device further comprises a network adapter for establishing a data communications channel to a cloud-based server; and b) the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine that the data communications channel is currently available, and to transmit the change in the player performance statistic to the cloud-based server over the data communications channel.
 34. The event monitoring system of claim 25, wherein the event monitoring program in the memory of the mobile computing device further includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values stored in the set of data objects, that one player in the plurality of players has lost possession of the basketball to another player.
 35. The event monitoring system of claim 25, wherein the event monitoring program in the memory of the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values in the set of data objects, that one player in the plurality of players has passed possession of the basketball to another player.
 36. The event monitoring system of claim 25, wherein the event monitoring program in the memory of the mobile computing device includes program instructions that, when executed by the microprocessor, will cause the microprocessor to determine, based on the possession change event type and said one or more values in the set of data objects, that one player in the plurality of players has taken possession of the basketball from another player.
 37. The event monitoring system of claim 25, wherein each player RFID reader and each goal RFID reader comprises a secondary RFID transceiver. 